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ABSTRACT 

Over  the  past  several  years,  researchers  within  the  ONR-sponsored  Adaptive 
Architectures  for  Command  and  Control  (A2C2)  research  program  have  been 
investigating  the  concept  of  organizational  “congruence”.  These  model-based 
theories  loosely  state  that  the  better  an  organization  is  matched  structurally  to  the 
overall  mission  (as  measured  using  a  multi-variant  set  of  workload/congruence 
metrics)  the  better  will  that  organization  perform  -  and  that  mismatches  are  potential 
drivers  for  adaptation  of  organization  structure. 

In  order  to  test  the  congruence  theories  and  their  corollaries  in  a  laboratory 
experiment,  our  approach  was  to  seek  two  sufficiently  disparate  organizational 
structures  and  then  design  two  missions  (or  scenarios)  that  would  exploit  the 
differences  in  these  two  structures.  One  scenario  would  be  “tuned”  to  organization  1 
to  exhibit  a  high  degree  of  congruence,  but  at  the  same  time  it  would  be 
“mismatched”  (i.e.,  exhibit  low  congruence)  with  organization  2.  Conversely,  the 
second  scenario  would  be  engineered  to  be  congruent  with  organization  1,  but 
incongruent  with  organization  2.  This  paper  describes  the  selection  of  the  two 
organizations,  and  the  model-driven  design  of  the  two  scenarios. 


1.  Introduction 

In  mid-2001  a  carrier  battle  group  was  underway  to 
its  new  assignment  in  the  Persian  Gulf.  Its  mission 
was  to  perform  a  presence  patrol  and  to  provide 
naval  aviation  to  conduct  Operation  Southern 
Watch.  The  battle  group  arrived  on  location  just 
after  the  September  1 1th  attack  on  the  World  Trade 
Center  and  the  Pentagon.  Thus,  its  mission  was 
changed  significantly  -  from  peacetime  presence 
and  Southern  Watch  to  playing  a  major  role  in 
Operation  Enduring  Freedom.  Many  aspects  of  the 
mission  were  different:  the  tempo  of  operations 
changed  from  a  moderate  tempo  (where  there  was 
time  allocated  for  maintenance  and  training  in 
addition  to  flying)  to  high-tempo  sustained 
operations  in  support  of  the  troops  (Special 
Operations  Force,  Marines,  Afghani  Freedom 
Fighters,  etc.)  on  the  ground.  The  mission  had  also 
changed  radically:  the  country  of  interest  was 
different  and  the  mission  tasks  were  different. 


That  is,  the  previous  tasks  that  involved  countering 
anti-aircraft  systems  and  an  integrated  air  defense 
system  changed  to  a  totally  different  set  of  tasks, 
i.e.,  all  in  support  of  ground  forces. 

This  actual  scenario  is  but  one  example  of  how 
military  forces  need  to  be  adaptable  to 
accommodate  changes  in  mission  that  will  occur  as 
part  of  the  nature  of  warfare.  In  response  to  this 
need,  the  Adaptive  Architectures  for  Command 
and  Control  (A2C2)  research  program  integrates 
optimization,  modeling,  and  simulation-based 
research  efforts  with  psychology-based  and 
experimental  activities  to  address  key  issues  in 
command  and  control.  The  research  has  followed 
a  model-experiment-model  paradigm  wherein 
models  produced  by  the  modeling/simulation 
efforts  support  the  formulation  of  hypotheses,  the 
determination  of  key  variables  and  parameter 
values,  and  the  prediction  of  organizational 
performance  and  processes  of  adaptation.  The 
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experimental  data,  in  turn,  are  collected  and 
produced  in  such  a  way  that  allows  for  both 
examination  of  the  hypotheses  and  ease  of  use  by 
the  modelers  for  post-experimental  model-data 
comparison  and  model  refinement. 

One  of  the  major  thrusts  of  the  A2C2  research  has 
been  the  development  of  models  and  constructs  to 
design  organizations  that  are  matched  to  a  given 
mission  that  they  plan  to  perform  [Levchuck  et  al, 
2002a,  2002b],  A  salient  factor  that  has  emerged 
from  this  work  is  the  concept  of  organizational 
“congruence”.  These  theories  loosely  state  that  the 
better  an  organization  is  matched  to  the  overall 
mission  (as  measured  using  a  multi-variant  set  of 
workload/congruence  metrics)  the  better  will  that 
organization  perform  -  and  that  mismatches  are 
potential  drivers  for  organizational  adaptation. 

Our  approach  for  testing  the  congruence  theories 
and  their  corollaries  via  laboratory  experiment  was 
to  first  seek  two  sufficiently  disparate  organiza¬ 
tional  structures  and  then  design  two  missions  (or 
scenarios)  that  would  exploit  the  differences  in 
these  two  structures.  In  this  “reverse  engineering” 
approach  one  scenario  would  be  “tuned”  to 
organization  1  to  exhibit  a  high  degree  of 
congruence,  but  at  the  same  time  this  scenario 
would  be  “mismatched”  (i.e.,  exhibit  low 
congruence)  with  organization  2.  Clearly,  the 
opposite  would  be  necessary  for  the  other  scenario. 

This  paper,  along  with  a  companion  paper  that 
focuses  extensively  on  the  concomitant  analytic 
modeling  [Levchuck  et  al,  2003],  describes  the 
selection  of  the  two  organizations,  and  the  model- 
driven  design  of  the  two  scenarios.  Section  2 
provides  the  background  that  lead  up  to  the 
experiment;  sections  3  and  4  define  the  overall 
operational/simulation  context  that  was  used; 
section  5  describes  the  two  organizational 
structures  that  were  selected;  and  section  6  gives 
the  details  behind  the  design/crafting  of  the  two 
scenarios.  The  experiment  -  number  8  on  the  list 
of  A2C2  empirical  milestones  -  was  conducted  at 
NPS  in  August  and  November  2002. 

2.  The  Road  to  Experiment  8 

Previous  A2C2  experiments,  and  the  concomitant 
models  that  supported  the  empirical  efforts, 
focused  extensively  on  the  design  of  organizations 
that  were  congruent  with  a  pre-defined  mission. 
Over  the  course  of  these  experiments,  that  have 


spanned  7+  years,  the  analytical  models  and  the 
experimentation  tools  -  most  notably  the 
Distributed  Dynamic  Decision-making  (DDD) 
simulator  [Kleinman,  1996]  -  have  undergone 
considerable  refinement,  improvement,  and 
extension  in  order  to  deal  with  the  increasing 
complexity  of  relevant  C2  issues  (e.g.,  self¬ 
synchronization,  network-centric  operations,  time- 
critical  targeting,  etc.).  Thus,  Experiment  8  had  a 
solid  basis  of  previous  work  to  guide  its  objectives 
and  design,  especially  the  goal  to  establish  the 
experimental  conditions  in  which  the  relationship 
between  congruence  and  performance  could  be 
tested. 

It  was  not  intended  that  Experiment  8  would  start 
from  “scratch”,  but  would  build  upon  and  adapt  an 
earlier  context/mission  setting  to  meet  our  research 
goals.  The  setting  that  we  chose  to  begin  from  was 
a  DDD  experiment  that  was  conducted  in  March 
2001  for  the  Chief  of  Naval  Operations  (N6C)  that 
investigated  the  processes  of  self-synchronization 
in  (six-person)  functionally-organized  versus 
divisionally/geographically-organized  teams.  See 
[Hutchins,  et  al,  2001].  That  experiment  was  not 
model-driven  and  employed  only  a  single  scenario. 
In  June  2001  the  A2C2  research  team  met  to 
operationalize  the  basic  approach  for  Experiment 
8.  It  was  decided  that  the  organizational  dimen¬ 
sion  would  use  a  functional  (F)  and  a  divisional 
(D)  structure  suitably  modified  from  those  used  in 
the  N6C  experiment.  Two  scenarios  would  be 
designed:  one  scenario  (d)  would  be  congruent 
with  organization  D  but  would  be  “misfit”,  or 
incongruent  to  organization  F.  Conversely,  the 
second  scenario  (f)  would  be  congruent  with 
organization  F  but  misfit  to  organization  D. 

Guided  by  the  above  operational  framework,  we 
undertook  to  design  a  preliminary  or  concept 
experiment  [Diedrich  et  al,  2002],  referred  to  as 
Concept-8  (C8),  which  had  several  purposes.  The 
first  was  to  design  and  test  modifications  to  the 
N6C  organizations  in  order  to  make  their  structures 
either  more  functional  or  more  divisional  -  i.e.,  to 
minimize  the  degree  of  commonality/overlap 
between  them  in  an  organizational  sense.  The 
second  aspect  of  the  C8  experiment  was  to  seek 
characteristics  (in  the  task  dimensions)  that  make 
certain  tasks  more  or  less  difficult  for  each  of  the 
two  organizational  structures.  This  was  accom¬ 
plished  by  examining  relative  performance  on 


individual  task  classes,  and  via  subject  post¬ 
experiment  questionnaire.  Another  aspect  of  the 
C8  work  involved  the  upgrading  and  testing  of  the 
DDD  simulator,  as  a  number  of  features  and 
enhancements  were  identified  as  being  crucial  to 
the  success  of  Experiment  8.  A  final  aspect  of  the 
C8  effort  involved  identification  of  measures  that 
would  be  needed  for  the  model-based  analysis  of 
Experiment  8,  and  the  development  and  introduc¬ 
tion  of  a  powerful  post-processor  tool  that  would 
supply  the  data  needed  to  calculate  those  measures. 

3.  Basic  Constructs  Behind  Experiment  8 

3.1  Military  Context  for  Experiment  8 
Experiment  8  (E8)  utilized  an  underlying  military 
situation  similar  to  that  used  in  the  C8  experiment. 
With  reference  to  Figure  1,  Country  A  has  invaded 
and  occupied  friendly  Country  B  and  has  also 
seized  Country  B’s  major  port  (PORT).  Currently, 
Joint  Task  Force  (JTF)  Agile  is  in  position  to 
commence  offensive  actions  to  drive  Country  A’s 
forces  out  of  Country  B.  If  attacked,  country  A  has 
threatened  to  use  tactical  ballistic  (SCUD)  missiles 
against  island  countries  D  and  E  that  are  U.S. 
allies.  In  addition  it  has  threatened  to  mine  the 
sea-lanes  to  shut  down  all  merchant  traffic  within 
the  region.  Country  C  is  sympathetic  to  Country 
A’s  cause,  and  could  align  with  Country  A  in 
opposing  U.S.  military  actions. 


Fig.  1  Experiment  8  Scenario  AOR 


Country  A’s  forces  are  concentrated  around  their 
naval  bases  (NBE,  NBW)  and  air  bases  (ABE, 


ABW),  and  are  protecting  a  major  bridge  (BR).  It 
is  likely  that  the  entrances  to  the  naval  bases  and 
port  have  been  mined.  The  enemy  has  an 
integrated  air  defense  system  that  includes  aircraft 
and  surface-to-air  missiles.  They  have  surface 
capability  in  the  form  of  fast  patrol  boats  and 
missile-firing  destroyers.  In  addition  they  have 
placed  their  coastal  defense  missiles  in  positions 
that  give  them  maximum  standoff  against  U.S. 
Navy  ships. 

Joint  Task  Force  Agile’s  objectives  are  to  establish 
air  and  sea  dominance  in  the  Area  of 
Responsibility  (AOR),  to  prepare  the  battlespace 
for  the  introduction  of  follow-on  ground  forces,  to 
protect  our  allies  in  the  region  from  SCUD 
missiles,  and  to  protect  itself  (and  neutral  shipping) 
from  enemy  air  and  sea  attack. 

3.2  Friendly  Forces  -  JTF  Agile 
A  number  of  modifications  were  made  to  the 
construct  of  the  JTF  based  on  lessons  learned  from 
the  C8  experiment.  We  replaced  ASW  operations 
with  mine-clearing  operations,  and  replaced  the 
JTF’s  submarine,  which  had  a  limited  role  due  its 
slow  speed,  with  a  third  DDG.  (Thus,  ASW  as  a 
warfare  area  was  removed  from  the  simulation.) 
We  increased  the  role/capability  of  the  FFG  (which 
was  somewhat  isolated  from  the  core  action  in  C8) 
by  giving  this  node  “control”  of  an  air  wing  - 
located  at  an  Air  Operations  Facility  (AOF)  on 
Island  E  -  thereby  enabling  the  FFG  to  be  involved 
in  air  defense  over  a  fairly  large  segment  of  the 
AOR.  We  further  modified  the  JTF  by  adding 
Special  Operations  Forces  (SOF),  preinserted  on  a 
Forward  Operating  Base  (FOB)  in  Country  A,  and 
created  relevant  offensive  ground  tasks  to  be 
accomplished  by  the  SOF  teams.  The  inclusion  of 
SOF  and  mine-clearing  operations  allowed  us  to 
increase  the  richness  and  complexity  of  the 
scenario(s)  that  would  ultimately  be  designed  via 
the  modeling  process. 

Figure  1  shows  the  fixed  location  of  the  six  major 
JTF  assets:  3  destroyers  (DDGA,  DDGB,  DDGC), 
a  frigate  (FFG),  cruiser  (CG)  and  aircraft  carrier 
(CVN),  plus  the  AOF  and  FOB  referred  to  above. 
These  locations  were  selected  to  provide  an 
“optimal”  anti-missile  shield  for  islands  D  and  E, 
to  guard  the  sea  lanes  (the  dark  lines  in  Figure  1) 
and  to  be  within  strike  range  of  key  targets  in 
country  A.  Each  platform  (or  node)  contains  a 


number  of  moveable  subplatforms  and/or  weapons 
systems.  A  subplatform  (e.g.,  a  fixed-wing 
aircraft,  helicopter,  UAV,  SOF  team,  etc.)  could  be 
“launched”  from  its  parent  platform,  maneuvered 
to  its  objective,  but  with  a  finite  time  duration  and 
weapon  load  (number  of  “shots”)  before  having  to 
return  for  refuel  or  reload.  The  weapons  on  a 
platform  (e.g.,  surface-to-air  missiles)  are  “fire  and 
forget”  but  are  limited  in  number. 


The  asset  structure  for  JTF  Agile,  that  remained 
exactly  the  same  over  all  runs  and  all  organizations 
for  Experiment  8,  is  detailed  in  Table  1.  Note  that 
all  three  DDG  nodes  have  the  same  load-out: 
6SM2,  2 HARP,  8TLAM,  4TTOM,  3 ABM,  1FAB, 
1HH60  and  1UAV.  The  carrier  node  has  2F18A, 
2F18S,  1MH53,  1FAB,  1HH60  and  1UAV,  etc. 
Allocating  the  various  subplatforms  and  weapons 
systems  to  the  major  platforms  was  done  with  a 
view  towards  equalizing  the  capabilities  of  the 
platforms,  while  still  trying  to  keep  these 
allocations  close  to  “reality”,  and  within  the 
workload  limits  of  players  who  might  be  acting  as 
commanders  of  the  major  nodes.  As  will  be 
discussed  in  Section  5,  it  is  the  different 
distribution  of  ownership  of  these  various  JTF 
assets  among  six  players  that  defines  the  two 
organizational  structures  used  in  Experiment  8. 


Some  of  the  other  information  in  Table  1  includes 
the  velocity  of  the  subplatforms  (mi/min),  their 
endurance  or  available  time,  and  the  number  of 
“shots”  each  can  take  before  needing  to  return  to 
its  parent  for  reload.  The  number  of  shots  is 
equivalent  to  the  number  of  tasks  that  a 
subplatform  can  process/attack  with  a  full  payload. 
The  velocities  are  approximately  10X  real-world 
values  as  the  game  is  played  at  a  10:1  time  scale. 


Some  additional  information,  not  shown  on  Table 
1,  included  the  subplatform  launch  and  weapon 
firing  delay,  and  the  duty  cycle  time  between 
successive  launches/firings. 

In  all  of  the  runs  the  six  (maneuverable)  UAVs 
were  pre-positioned  in  theatre  at  game  start.  This 
avoided  the  lengthy  start-up  times  as  per  C8 
needed  to  launch  and  fly  the  UAVs  into  position. 
In  addition  to  the  UAVs,  each  platform  and 
subplatform  (but  not  weapon)  had  sensor  ability 
for  detecting  and  identifying  air,  sea  or  ground 
contacts.  The  sensor  ranges  for  a  given  asset  were 
generally  different  for  different  media,  and  often 
depended  on  the  class  of  contact  being  sensed. 

3.3  Resource  Categories  and  Asset  Capabilities 
The  manner  in  which  we  model  the  capabilities  of 
the  various  assets  and  weapons  has  proven  itself  to 
be  extremely  flexible  in  past  efforts.  The  paradigm 


fixed  platforms 

mi/min 

loadout  (subplatforms  and  weapons) 

DDGA 

Aegis-capable  destroyer 

0 

6SM2,  2 HARP,  8TLAM,  4TTOM,  3ABM,  1  FAB,  1HH60,  1  UAV 

DDGB 

Aegis-capable  destroyer 

0 

6SM2,  2HARP,  8TLAM,  4TTOM,  3ABM,  1FAB,  1HH60,  1  UAV 

DDGC 

Aegis-capable  destroyer 

0 

6SM2,  2HARP,  8TLAM,  4TTOM,  3ABM,  1FAB,  1HH60,  1  UAV 

FFG 

Aegis-capable  frigate 

0 

4SM2,  2HARP, 

1MH53,  1FAB,  1HH60,  1  UAV 

CG 

Aegis-capable  cruiser 

0 

6SM2,  2HARP,  8TLAM,  3ABM,  1MH53,  1FAB,  1HH60,  1  UAV 

CVN 

Aircraft  carrier 

0 

2F18A,  2F18S, 

1MH53,  1FAB,  1HH60,  1UAV 

E2C 

AW  ACS  -  aircraft 

"o 

sensors  only  -  prepositioned  for  total  air  surveillance  in  AOR 

FOB 

forward  operating  base 

0 

3SOF  teams  preinserted  in  Country  A 

AOF 

air  ops  facility  on  Island  E 

0 

2F18A,  2F18S 

subplatforms  (reloadable) 

mi/min 

Tavail 

#  shots 

weapons 

mi/sec 

range 

F18A 

air-to-air  defender 

200 

15min 

2 

SM2  standard  surface- 

5.0 

100mi 

air  missile 

F18S 

air-to-ground  strike  aircraft 

200 

15min 

1 

ABM  anti-ballistic  missile 

7.0 

85mi 

MH53 

helicopter  mine  clearer 

40 

60min 

2 

TLAM  Tomahawk  cruise 

2.0 

360mi 

missile 

HH60 

search  and  rescue  helo 

45 

18min 

1 

TTOM  tactical/steerable 

2.0 

500mi 

Tomahawk 

UAV 

unmanned  recon  vehicle 

30 

60min 

n/a 

HARP  Harpoon  anti-ship 

1.5 

60mi 

sensor  only 

missile 

FAB 

fast  attack  boat 

25 

20min 

2 

SOF 

special  ops/SEAL  team 

40 

60min 

00 

Table  1 :  Friendly  Order  of  Battle  -  Task  Force  Agile 


adopted  for  our  model-driven  experiments  first 
defines  a  set/vector  of  resources  R  =  [rl,  r2,  ...  ] 
that  is  relevant  to  the  problem  context  at  hand. 
Each  element  ri  defines  a  resource  category  or 
warfare  area.  Then,  every  asset  is  assigned  a 
numerical  value  for  each  element  ri,  which  defines 
that  asset’s  resource  capabilities  vector.  In 
addition,  each  task  that  is  contained  within  the 
scenario  is  assigned  a  vector  of  resource 
requirements.  The  paradigm  requires  the  team  to 
prosecute  tasks  in  such  a  way  that  a  task’s  resource 
requirements  are  met  by  the  summed  resource 
capabilities  of  the  assets  allocated  to  that  task.  For 
E8  the  selected  set  of  resource  categories  were: 

R  =  [AAW,  Mines,  ASuW,  BMD,  Strike,  SAR,  SOF] 

With  these  definitions,  the  capabilities  of  the  assets 
in  JTF  Agile  are  given  in  Table  2.  Note  that  for 
this  experiment  we  have  elected  to  use  1  or  0  to 
indicate  whether  or  not  a  particular  asset  (platform, 
subplatform,  or  weapon)  has  capability  in  any 
particular  resource  category,  as  opposed  to  using  a 
continuum  scale.  Thus,  a  surface-to-air  standard 
missile  (SM2)  has  AAW  capability,  as  does  an 
F18A.  [The  one  exception  here  is  the  F18S  that 
has  2  units  of  STRIKE  to  indicate  that  its  one 
attack  has  twice  the  “punch”  of  a  TLAM.]  In 


Name 

Description 

AAW 

Mines 

ASuW 

BMD 

Strike 

SAR 

SOF 

platforms: 

DDGA  destroyer 

0 

0 

0 

0 

0 

0 

0 

DDGB 

destroyer 

0 

0 

0 

0 

0 

0 

0 

FFG 

frigate 

0 

0 

0 

0 

0 

0 

0 

CG 

cruiser 

0 

0 

0 

0 

0 

0 

0 

CVN 

Aircraft  carrier 

0 

0 

0 

0 

0 

0 

0 

DDGC 

destroyer 

0 

0 

0 

0 

0 

0 

0 

E2C 

Air  survellance  a/c 

0 

0 

0 

0 

0 

0 

0 

subplatforms: 

FI 8 A  Air-to-air  defender 

1 

0 

0 

0 

0 

0 

0 

F18S 

Strike  aircraft 

0 

0 

0 

0 

2 

0 

0 

MH53 

Mine  clearing  helo 

0 

1 

0 

0 

0 

0 

0 

HH60 

Search  &  rescue  helo 

0 

0 

0 

0 

0 

1 

0 

UAV 

Pilotless  sensor  a/c 

0 

0 

0 

0 

0 

0 

0 

FAB 

Fast  attack  boat 

0 

0 

1 

0 

0 

0 

0 

SOF 

Special  Ops  unit 

0 

0 

0 

0 

0 

0 

1 

weapons: 

SM2  Surface-to-air  missile 

1 

0 

0 

0 

0 

0 

0 

ABM 

Anti-ballistic  missile 

0 

0 

0 

1 

0 

0 

0 

TLAM 

Tomahawk  missile 

0 

0 

0 

0 

1 

0 

0 

TTOM 

Tactical  Tomahawk 

0 

0 

0 

0 

1 

0 

0 

HARP 

Anti-ship  missile 

0 

0 

1 

0 

0 

0 

0 

Table  2:  Asset  Resource  Capabilities 


particular  note  that  we  have  gone  to  great  lengths 
to  give  each  asset  capability  in  only  one  resource 
category.  While  this  may  ignore  the  multi¬ 
functional  capability  of  some  subplatforms,  it  was 
done  to  keep  the  associated  modeling  “clean”  so 
that  assets  would  not  be  considered  for  use  in  areas 
other  than  in  their  primary  ones. 

Another  fact  to  note  is  that  the  six  primary 
platforms  do  not  have  any  native  or  organic 
capabilities  -  all  of  their  capabilities  derive  from 
their  subplatforms  and  weapons  systems.  This  is  a 
change  from  C8  where  the  self-defense  of  a 
particular  platform  using  its  organic  systems 
became  confounded  with  player  roles  in  a 
functional  organization.  Thus,  the  defense  of  a 
platform  must  now  be  accomplished  by  using  the 
various  JTF  assets  located  on  that  platform  as  well 
as  elsewhere. 

4.  Mission  Task  Graph 

The  greatest  limitation  of  C8  for  model-driven 
experimentation  was  the  fact  that  there  was  no 
mission  plan  (i.e.,  task  graph)  that  defined  a 
sequence  of  tasks  or  course  of  action  that  the  JTF 
was  to  accomplish.  Experiment  C8  dealt  primarily 
with  destroying  enemy  forces  and  self-defense, 
with  no  clear  statement  of  what  the  “mission” 
objective  was.  This  was  a  source  of  complaint  by 
the  players,  which  we  sought  to  remedy  in 
Experiment  8.  Moreover,  the  modeling  approach 
requires  a  task  graph  in  order  to  determine  the 
“optimal”  allocation  of  assets  to  tasks  in  order  to 
minimize  the  time  span  of  the  mission.  Thus,  a 
well-defined  mission  is  a  backbone  to  both  the 
experimental  and  analytical  parts  of  the 
Experiment  8  effort,  and  provides  a  yardstick  to 
measure  the  progress  of  teams  as  they  move  along 
in  space  and  time  to  complete  the  mission. 

A  task  graph  is  basically  a  mission  plan  or  course 
of  action  (COA)  that  shows  the  precedence 
relations  among  tasks.  After  considerable 
adjustment  via  modeler-experimenter  iteration,  the 
task  graph  that  emerged  for  E8  is  shown  in  Figure 
2.  Since  our  objective  was  to  design  two  scenarios, 
we  made  the  decision  that  both  scenarios  would  be 
based  on  the  same  task  graph,  with  the  salient 
differences  being  only  in  the  individual  task 
requirements  and  enemy  force  dispositions.  One 
of  our  original  thoughts  was  to  construct  the  two 
scenarios  to  have  radically  different  task  graphs  or 


missions  (e.g.,  disaster  relief  versus  amphibious 
operation).  But  the  reality  of  needing  to  train 
subjects  to  perform  two  very  different  missions  in 
the  limited  time  these  players  were  available  to  the 
project  made  such  an  approach  infeasible  -  not  to 
mention  the  time  and  resources  that  it  would  have 
taken  to  build  a  second  scenario. 


Fig.  2:  Mission  Task  Graph,  Experiment  8 


The  mission  tasks  are  shown  as  circles  in  Figure  2. 
These  are  the  tasks  that  must  be  done,  are  “known” 
and  planned  for  in  advanced,  and  generally  follow 
a  prerequisite  structure  that  establishes  a  task 
processing  sequence.  This  course  of  action  or  plan 
first  destroys  the  enemy  command  center  (CTR) 
and  then  (with  the  aid  of  SOF)  captures  ABE  and 
NBE  that  will  serve  as  bases  for  the  introduction  of 
our  follow-on  air  and  sea  forces.  ABE  and  NBE 
are  likely  to  be  defended  by  ground  forces  (RGF) 
that  present  obstacles  to  the  SOF  teams.  In 
addition,  mines  at  the  entrance  to  NBE  need  to  be 
cleared.  In  parallel  with  the  above  tasks,  first 
NBW  and  then  ABW  are  to  be  destroyed.  Prior  to 
destroying  ABW  it  is  necessary  to  destroy  a  key 
bridge  on  the  road  between  NBW  and  ABW  to 
deny  the  enemy  his  ability  to  reinforce  ABW. 
Mobile  SAM  sites  (SA3)  protect  ABW.  Having 
completed  ABW  and  NBE,  the  final  objective  of 
securing  Country  B’s  PORT  can  be  achieved  once 
the  mines  have  been  cleared.  Several  of  the 
mission  tasks,  especially  those  that  need  SOF  to 
accomplish,  may  spawn  an  evacuation  of  wounded 
(EVA)  as  a  consequence  of  performing  that  task. 
These  medivac/EVA  tasks  are  shown  symbolically 
on  the  task  graph  as  an  M  within  an  oval. 


Other  tasks  shown  in  Figure  2  are  the  search  and 
rescues  (SARs),  which  we  treat  as  high  priority 
mission  tasks,  and  the  desire  to  clear  SAM  sites  in 
the  northern  half  of  Countries  A  and  B  to  allow 
unhampered  use  of  this  airspace.  A  primary 
(aggregated)  task  of  the  JTF  is  to  protect  the  island 
countries  D  and  E  from  SCUD  missile  attacks, 
either  by  destroying  the  launchers  (SML)  on  the 
ground  or  shooting  down  the  launched  missiles 
(AMIS).  The  JTF  also  must  protect  its  own  assets 
from  enemy  air  and  surface  threats.  These 
aggregated  defend  tasks  are  shown  symbolically  in 
Figure  2  along  with  the  possible  subtasks  that 
make  up  the  higher-level  task. 

As  noted,  two  scenarios  were  constructed  based  on 
the  task  graph  of  Figure  2,  where  a  major  factor 
distinguishing  the  scenarios  was  the  requirements 
vector  for  each  of  the  individual  task  classes.  The 
development  of  the  two  scenarios  is  given  in 
section  6. 

5.  Selection  of  Organizational  Structures 

The  precursor  C8  experiment  examined  both  a 
functional  (F)  and  a  divisional  (D)  six-node 
organizational  structure  performing  a  single 
mission  that  consisted  of  a  variety  of  complex 
tasks.  The  primary  distinctions  between  the  two 
structures  were  asset  ownership  (who  owned  what) 
and  locus  of  responsibility.  The  functional 
structure  was  organized  such  that  each  commander 
specialized  in  a  single  aspect  of  the  mission  (e.g. 
strike  or  surface  warfare)  over  the  entire  battle 
space,  controlling  relevant  assets  that  were 
distributed  across  multiple  platforms  (ships).  By 
contrast,  commanders  in  the  divisional  structure 
controlled  a  single  multi-functional  platform  (e.g., 
DDG  or  CVN)  that  to  a  large  extent  was  able  to 
process  a  variety  of  functional  tasks  in  only  a 
portion  of  the  battle  space.  The  organizations 
selected  for  the  current  experiment  were 
modifications  and  refinements  to  those  of  C8. 

The  C8  experiment  hinted  that  testing  the 
congruence  theories  in  an  experimental  setting 
would  be  best  served  if  the  “distance”  between  the 
two  organizational  structures  (F  and  D)  was 
maximized  to  mitigate  the  inevitable  variance 
when  dealing  with  human  teams.  Thus,  it  was 
prudent  to  further  “separate”  the  F  and  D 
organizations  to  obtain  two  extreme  cases  of  these 
organizational  structures.  We  took  guidance  from 


the  research  work  at  Michigan  State  University 
that  examined  a  four-person  team  that  was 
organized  across  either  functional  or  divisional 
lines  [Hollenbeck  et  al,  2002],  Thus,  we  strove  to 
have  each  node  in  the  D  organization  have 
capability  in  as  many  functional  warfare  areas  as 
possible.  Likewise,  it  was  desired  that  each 
functional  node  would  control  associated 
functional  assets  (subplatforms  or  weapons) 
distributed  over  all  six  primary  platforms  -  with 
little  or  no  overlap  in  functional  areas  among  the 
nodes. 

The  selection  of  assets  within  the  composite  JTF 
and  their  capabilities  proscribes  what  is  capable  of 
being  achieved  organizationally.  These  assets  - 
and  their  allocation  to  parent  platforms  as  shown  in 
Table  1  plus  their  capabilities  as  in  Table  2  -  were 
crafted  to  best  allow  for  building  an  F  and  D 
organization  that  met  the  above-noted  design 
goals.  Associated  with  this  asset  mix  is  the 
following  set  of  eight  possible  functional  warfare 
areas: 

AAW  =  anti- air  warfare 
Mines  =  mine-clearing  operations 
ASuW  =  anti-surface  warfare 
BMD  =  ballistic  missile  defense 
Strike  =  strike  warfare 
SAR  =  search  and  rescue 
SOF  =  special/ground  operations 
ISR  =  intel/survellance/recon 

Note  that  these  warfare  areas  closely  follow  the 
categories  in  the  resource  vector.  An  early 
decision  in  the  design  of  Experiment  8  was  to 
constrain  the  organization(s)  to  six  player  or 
decisionmaker  (DM)  nodes  -  all  at  the  same  level 
-  plus  a  seventh  node  (DM0)  which  represented 
the  CJTF.  This  was  identical  to  the  structure  that 
was  used  in  the  previous  N6C  and  C8  experiments. 
The  CJTF  was  actually  present  in  the  experiment 
but  was  not  involved  actively  in  the  game  play  and 
owned  no  assets.  [However,  the  CJTF  node  was  a 
useful  element  in  the  training/mission  rehearsal 
trials.]  The  six-node  limit  meant  that  some  nodes 
or  players  in  F  would  have  to  assume  two  hats: 
We  combined  Mines  with  ASuW,  and  SOF  with 
SAR  as  these  aggregations  made  the  most  sense 
operationally.  The  D  organization  was  relatively 
straightforward  as  each  of  the  six  player  nodes 


corresponded  to  one  of  the  major  platforms  in 
Table  1. 

With  the  nodes  so  defined,  the  allocation  of  assets 
to  nodes  for  both  the  D  and  F  organizations  is 
shown  in  Table  3.  The  divisional  (D)  organization 
nodes  are  shown  in  the  horizontal  rows  and  reflect 
the  assets  and  weapons  on  the  major  platforms.  In 
this  organization  a  player  is  a  platform 
commander.  The  aircraft  “owned”  by  the  FFG  are 
those  located  on  the  AOF  on  Island  E.  Each  of  the 
three  DDG  nodes  “owns”  one  of  the  SOF  units  on 
the  FOB.  Note  that  every  node  was  given 
capability  in  most  of  the  eight  warfare  areas  (albeit 
of  a  somewhat  differing  nature)  except  for  the 
CVN  and  FFG  in  BMD,  the  CVN,  FFG  and  CG  in 
SOF,  and  the  DDGs  in  Mines.  This  was  done  to 
balance  platform  loadings  so  that  individual 
players  in  D  would  not  be  overloaded  with 
(heterogeneous)  assets  to  control.  It  is  also 
important  to  bear  in  mind  that  many  of  the 
capabilities  of  a  particular  node  in  D  extend  only 
within  its  local  geographical  region  due  to  finite 
weapon  ranges  and  subplatform  endurance  times. 


STRIKE 

BMD 

ISR 

AWC 

SuWC/MINES 

SOF/SAR 

CVN 

2F18S 

XXX 

1UAV 

2F18A 

1FAB 

1MH53 

1HH60 

DDGA 

8TLAM 

3ABM 

4TTOM 

1UAV 

6SM2 

1FAB,  2 HARP 

1HH60 

1SOF 

DDGB 

8TLAM 

3ABM 

4TTOM 

1UAV 

6SM2 

1FAB,  2 HARP 

1HH60 

1SOF 

CG 

8TLAM 

3ABM 

1UAV 

6SM2 

1  FAB.2HARP 
1MH53 

1HH60 

FFG 

2F18S 

XXX 

1UAV 

2F18A 

4SM2 

1FAB.2HARP 

1MH53 

1HH60 

DDGC 

8TLAM 

3ABM 

4TTOM 

1UAV 

6SM2 

1FAB,  2 HARP 

1HH60 

1SOF 

Table  3:  D  and  F  Organizational  Structures 


The  functional  (F)  organizational  nodes  are 
depicted  vertically  in  the  columns  of  Table  3.  In 
this  organization  a  player/DM  node  “owns”  all  of 
the  assets  relevant  to  his/her  warfare  area  across 
the  entire  AOR.  Each  player,  then,  is  a  warfare 
area  commander.  In  addition,  the  operating 
environment  for  the  game  was  such  that  any  player 
(e.g.,  Strike  Warfare  Commander)  had  the 
authority  to  launch  aircraft  or  fire  TLAM  from  any 
platform.  It  was  implicitly  assumed  that  each 
warfare  area  commander  was  “located”  on  a 


particular  platform,  although  this  had  no  bearing 
on  the  actual  game  play.  For  reference,  the  Strike 
Commander  was  assumed  to  be  located  on  the 
CVN,  the  BMD  Commander  on  the  DDGA,  the 
ISR  Commander  on  the  DDGB,  the  AWC  on  the 
CG,  the  ASuWC/MWC  on  the  FFG,  and  the 
SOF/SAR  Commander  on  the  DDGC. 

One  of  the  goals  in  building  the  F  organization  was 
to  have  no  overlap  in  capabilities  across  functional 
areas.  This  was  largely  achieved,  as  each  asset  has 
capability  in  just  one  resource  dimension  as  shown 
in  Table  2.  However,  there  were  some  exceptions: 
1)  All  subplatforms  (FI 8s,  HH60,  etc.)  have  some 
ISR  capability;  hence  ISR  is  not  unique  to  only  the 
UAVs.  We  mitigated  this  overlap  in  ISR  among 
warfare  commanders  by  emphasizing  the  role  of 
the  UAVs  for  ground  ISR  within  Countries  A  and 
B,  and  reducing  the  ISR  capability  of  the  FI 8s  to 
detect/identify  ground  contacts.  2)  The  tactical 
tomahawks  (TTOMs)  do  have  strike  capability,  yet 
the  BMD  commander  owns  these  assets.  In  the 
experiment  we  stressed  the  importance  of  the 
TTOM  as  the  weapon  of  choice  for  destroying 
SCUD  missile  launchers,  and  severely  limited  their 
number  within  the  JTF  to  help  assure  that  TTOMs 
would  not  be  used  for  “normal”  strike  operations. 
Conversely,  the  scenarios  were  designed  to  make  it 
difficult  to  destroy  a  SML  using  a  TLAM  (that  is, 
it  was  imperative  to  have  a  weapon  in  the  area 
given  the  short  set-up  and  fire  time  of  SCUDs), 
and  using  an  F18S  would  be  “overkill”. 

6,  Scenario  Design 

As  has  been  noted,  the  objective  was  to  design  two 
scenarios  -  each  based  upon  the  task  graph  of 
Figure  2  -  such  that  one  scenario  (d)  would  be 
congruent  with  organization  D  but  misfit  or 
incongruent  to  organization  F.  Conversely,  the 
second  scenario  (f)  would  be  congruent  with 
organization  F  but  misfit  to  organization  D.  One 
of  the  underlying  hypotheses  that  we  are  testing  is 
that  congruence  between  organization  and  mission 
leads  to  good  performance,  i.e.,  organizations  that 
are  congruent  with  their  mission  will  perform 
better  than  those  that  are  incongruent. 

In  this  section  the  design  of  scenarios  d  and  f  are 
discussed.  Several  factors  drove  the  design. 

6.1  Resource  Requirements  for  Task  Classes 


The  two  organizations  differed  primarily  with 
respect  to  the  assets  (and  hence  the  resource/ 
functional  capabilities)  that  each  DM  node  owned. 
The  congruence  model  postulates  that  inter-DM 
coordination  is  a  major  contributor  to  workload, 
and  that  the  degree  of  predicted  (structural) 
congruence  is  inversely  related  to  the  amount  of 
inter-DM  (inter-nodal)  coordination  needed  to 
accomplish  the  mission.  Therefore,  by  adjusting 
the  resource  requirements  of  selected  task  classes  it 
becomes  possible  to  manipulate  the  inter-DM 
coordination  needed  to  successfully  prosecute 
these  tasks  for  a  given  organization-scenario 
pairing.  Thus,  we  set  out  to  design  a  number  of 
tasks  within  scenario  f  such  that  little  coordination 
would  be  needed  within  organization  F,  while 
significant  coordination  would  be  needed  by 
organization  D.  The  case  is  reversed  for  scenario  d 
wherein  tasks  must  be  designed  to  favor  D  while 
being  mismatched  to  F.  For  example,  a  task 
requiring  a  single  asset  in  each  of  three  functional 
areas  would  need  three  DMs  to  coordinate  in  F,  but 
could  be  performed  by  a  single  DM  in  D  - 
provided  that  he/she  owned  assets  in  all  of  the 
requisite  areas.  Similarly,  a  task  requiring  multiple 
assets  in  a  single  functional  area  is  well-suited  to  F, 
but  would  need  multiple  players  in  organization  D 
to  “pool”  their  assets. 

The  task  classes  considered  for  this  coordination 
manipulation  included:  (1)  all  of  the  key  “mission” 
tasks  as  shown  in  the  task  graph  of  Figure  2,  and  to 
a  lesser  extent  (2)  search  and  rescue,  mine  clearing, 
SAM  sites  and  enemy  destroyers.  To  both  the  f 
and  d  scenarios  we  further  added  a  number  of 
time-critical  “pop-up”  or  unanticipated  tasks  that 
have  complex  resource  requirements,  such  as  have 
the  mission  tasks.  These  were  high  priority  tasks 
that  need  to  be  accomplished  in  a  finite  time 
window  -  e.g.  a  white  merchant  ship  hitting  a  mine 
or  coming  under  attack  by  hostile  aircraft.  For 
each  of  the  f  and  d  scenarios  we  added  between  5-7 
such  tasks,  thereby  providing  an  additional  means 
to  further  manipulate  (in)congruence. 

Task  Resource  Requirements:  Scenario  d 
The  list  of  task  classes  within  scenario  d  is  given  in 
Table  4.  There  were  a  total  of  35  task  classes  used 
in  the  design  of  this  scenario,  where  the  number  of 
instantiations  (i.e.,  individual  tasks)  of  each  class 
ranged  between  1  and  20  depending  on  the  class. 
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Table  4:  Task  Resource  Requirements,  Scenario  d 

An  example  of  how  a  task’s  resource  requirement 
differentially  drives  the  coordination  demands 
within  D  and  F  is  shown  by  the  mission  task  NBE 
(“destroy  Naval  Base  East”).  This  task  needs  1 
unit  of  ASuW,  2  units  of  Strike,  and  1  unit  of  SOF. 
In  the  D  organization  any  one  of  three  DDG 
commanders  could  accomplish  the  task  alone,  with 
no  inter-DM  coordination  required.  [With 
reference  to  Table  3  each  DDG  “owns”  a  SOF  unit, 
TLAM  strike  assets  and  a  fast  attack  boat  (FAB).] 
On  the  other  hand,  three  players  in  the  F 
organization  -  the  Strike,  ASuW  and  SOF/SAR 
warfare  area  commanders  -  would  need  to 
coordinate  to  properly  process  this  task.  But 


coordination  must  have  an  element  of  time 
synchronization  if  it  is  to  be  meaningful  in  our 
experimental  setting.  In  the  scenario  each  task  had 
a  time  window  (Tw)  within  which  all  of  the  assets 
allocated  to  that  task  must  commence  their 
individual  attacks.  The  NBE  had  a  Tw  of  40sec. 
Once  the  first  asset  allocated  to  NBE  begins  its 
attack,  a  40sec  countdown  begins  within  which 
time  all  of  the  additional  assets  allocated  to  NBE 
must  begin  their  attack.  If  less  than  the  task’s  full 
resource  requirements  are  met  the  team  receives 
only  a  partial  score  on  the  task.  The  value  of  Tw 
for  each  task  class  roughly  scaled  with  the  number 
of  assets  needed  for  task  processing. 

The  high-priority  (unanticipated)  tasks  are  listed  as 
TSK  in  Table  4.  There  were  three  such  classes 
with  two  task  instantiations  in  each.  Note  that  the 
resource  requirements  span  a  number  of  warfare 
areas,  yet  in  all  cases  the  tasks  were  designed  to  be 
accomplished  by  a  single  DM  in  organization  D. 
In  selecting  the  requirements  for  these  multi¬ 
resource  tasks,  care  was  taken  to  assure  that  the 
tasks  would  appear  to  be  “realistic”,  i.e.,  requiring 
assets  that  might  normally  work  together.  These 
TSK  tasks  (as  well  as  the  slightly  less  complex 
S&R,  HOS,  EVA)  are  time-critical,  i.e.,  unlike  the 
mission  tasks,  they  must  be  accomplished  before  a 
deadline  or  else  they  “disappear”  or  expire.  This 
places  an  added  stress  upon  the  players  by  urging 
them  to  react  in  a  timely  manner. 

Task  Resource  Requirements:  Scenario  f 
The  list  of  task  classes  within  scenario  f  is  given  in 
Table  5.  There  were  also  a  total  of  35  task  classes 
used  here,  with  most  having  the  same  name  as  in 
scenario  d,  but  with  considerably  different 
resource  requirements.  For  example,  the  NBW 
mission  task  requires  six  units  of  strike  in  this 
scenario.  In  the  F  organization  the  Strike 
commander  can  accomplish  this  task  as  a  single 
DM  using  a  combination  of  F18S  (from  the  CVN 
or  AOF)  and/or  TLAM  fired  from  any  of  4 
platforms.  On  the  other  hand,  in  the  D 
organization  two  or  three  players  must  coordinate 
to  synchronize  their  attack  using  their  strike  assets. 
Note  that  each  DDG  or  CG  commander  possesses 
enough  TLAM  assets  to  accomplish  the  NBE  task 
by  himself.  However,  the  NBE’s  time  window  of 
40s,  coupled  with  an  imposed  time  delay  of  23  s 
between  successive  TLAM  launches,  implies  that 
no  more  than  two  TLAMs  from  a  single  platform 
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Table  5:  Task  Resource  Requirements,  Scenario  f 

can  be  used  to  attack  NBE.  A  similar  construct 
exists  for  most  other  task  classes  requiring  strike 
assets.  For  example,  the  SAM  sites  that  require 
two  units  of  strike  within  a  20s  window,  must  be 
accomplished  via  a  two-DM  coordination  in  the  D 
organization,  but  can  be  accomplished  by  the 
Strike  Commander  in  F  acting  alone. 

The  resource  requirements  for  the  major  mission 
tasks  in  f  were  adjusted  to  require  coordination 
among  two  or  more  DMs  in  D  but  not  in  F. 
Another  example  of  the  need  for  multi-person 
intra-task  coordination  is  the  Air  base  East  (ABE) 
that  needs  three  DMs  to  coordinate  to  satisfy  the 
3SOF  resource  requirement.  In  addition  to  these 
mission  tasks,  the  unanticipated  and  time-critical 
tasks  were  crafted  to  place  further  demands  on 


team  coordination.  These  tasks  are  not  directly 
part  of  the  mission  task  graph  to  allow 
considerable  flexibility  on  the  location  and  timing 
of  their  appearance  in  the  scenario.  When 
designing  the  requirements  and  locations  for  many 
of  these  tasks  it  became  necessary  to  assure  that 
the  tasks  could  indeed  be  accomplished  (in  the 
time  allotted)  by  the  assets  that  the  organization 
owns!  For  example,  the  search  and  rescue  (S&R) 
tasks  require  2  units  of  SAR;  the  mine  tasks  (MIN) 
require  2  units  of  MIN,  etc.  However,  the  team 
has  a  limited  number  of  HH60s  (the  SAR-capable 
assets),  and  MH53s  (used  for  mine  clearing). 
Model-based  analysis  was  used  extensively  to 
assure  that  limited  assets  could  indeed  be 
scheduled  to  accomplish  all  of  the  tasks.  For  some 
task  classes,  timing  and  location  of  tasks  were 
modified;  for  some  other  classes  it  was  necessary 
to  reduce  the  number  of  tasks.  To  assure  that  tasks 
(and  even  the  overall  mission)  would  be  accom¬ 
plished  in  a  reasonable  time,  asset  velocities  were 
increased  when  necessary.  In  addition,  NPS 
students  “play-tested”  both  the  f  and  d  scenarios  to 
further  assure  that  the  design  goals  were  being  met, 
and  adjustments  were  make  as  necessary. 

6.2  Inter-task  Coordination 

Adjustment  of  task  resource  requirements  was 
used  as  a  primary  manipulator  of  intra-task 
coordination.  In  addition,  inter-task  coordination 
was  manipulated  in  the  d  and  f  scenarios  largely 
via  the  task  dependency  structure  as  exhibited  in 
the  task  graph.  Successive  tasks  in  the  task  graph 
have  an  implied  information  flow  due  to  their 
precedence  order  -  task  B  cannot  be  started  until 
prerequisite  task  A  is  completed.  This  has 
implications  for  asset  management  as  regards  the 
preparation/readiness  of  assets  for  the  downstream 
tasks.  If  successive  tasks  involve  different  DMs 
then  information  on  the  status/planning  of 
prerequisite  tasks  must  be  passed  between  DMs, 
thus  requiring  inter-DM  information  coordination. 

If  contiguous  pieces  of  the  task  graph  could  be 
allocated  to  a  single  DM  (via  the  design  of 
resource  requirements  of  tasks  and  their  immediate 
prerequisites)  inter-DM  coordination  would  be 
reduced.  To  the  extent  that  this  was  possible,  the 
task  graph  was  built  to  minimize  inter-task 
coordination  by  DMs  in  the  congruent  situations 
(Dd  and  Ff)  and  to  require  inter-task  coordination 
among  successive  tasks  in  the  non-congruent 


situations  (Df  and  Fd).  For  example,  in  the  f 
scenario  (see  Table  5  and  Figure  2)  the  lower 
branch  of  the  task  graph  has  a  heavy  dependence 
on  SOF  assets  and  is  largely  allocated  to  the  SOF 
commander  in  F;  the  upper  branch  is  largely  under 
the  responsibility  of  the  Strike  Commander.  In 
scenario  d  (see  Table  4)  the  multi-resource  tasks 
were  designed  so  that  one  of  the  DDG 
commanders  in  D  would  have  the  assets  and 
responsibility  for  the  tasks  in  the  east  (lower 
branch);  another  DDG  commander  could  handle 
the  west  (upper  branch).  Clearly,  in  the  mis¬ 
matched  or  incongruent  situations,  different  DMs 
are  needed  to  process  successive  tasks  simply  as  a 
result  of  the  different  resource  requirements. 
While  this  was  not  a  major  manipulation  in  the 
scenario  design  process  for  this  experiment,  it  can 
prove  to  be  a  very  salient  mechanism  for 
manipulating  congruence  in  situations  that  have 
higher  inter-task  information  flow  requirements  - 
especially  in  those  cases  where  the  team  does  not 
have  a  global  (common)  information  structure. 

6.3  Spatial-Temporal  Loading 
The  adjustment  of  arrival  times,  locations  and 
trajectories  of  the  many  task  classes  that  make  up 
the  “defend”  tasks  provides  a  second  powerful 
mechanism  to  adjust  the  f  and  d  scenarios  vis-a-vis 
the  two  organizations.  The  resource  requirements 
focussed  on  manipulating  coordination;  the  spatial- 
temporal  mechanism  manipulated  (differential) 
loading  among  the  team’s  DMs.  The  task  classes 
that  fall  into  this  category  include: 

AC  =  enemy  air  attackers 
APH  =  possibly  hostile  aircraft  (about  50%  are 
indeed  hostile) 

CDM  =  cruise  missiles  fired  from  coastal 
defense  launchers  (CDLs) 

MIN  =  enemy  mines  (except  those  that  are 
mission  task  prerequisites) 

PT  =  enemy  patrol/missile  boats 
DG  =  enemy  missile-firing  destroyers 
SPH  =  possibly  hostile  surface  craft  (about 
50%  are  indeed  hostile) 

The  timing  and  location  of  sea  search  and  rescue 
tasks  (S&R)  were  also  part  of  this  manipulation. 
Most  of  these  task  classes  had  simple  resource 
requirements:  for  example  a  single  unit  of  AAW  or 
ASuW  for  AC  and  PT,  respectively.  However, 
each  scenario  contained  a  large  number  (13-15)  of 


such  tasks,  thereby  allowing  for  the  construction  of 
task  “waves”  to  vary  the  workload  for  different 
DMs  in  a  carefully  orchestrated  manner. 

Spatial-Temporal  Loading:  Scenario  d 
In  scenario  d  the  task  “waves”  were  built  to  be 
relatively  easy  for  players  in  D,  while  being 
difficult  for  players  in  F.  Thus,  the  waves  typically 
consisted  of  many  tasks  with  the  same  resource 
requirements  spread  over  a  broad  geographical 
area  -  for  example  a  large  coordinated  enemy  air 
attack  that  simultaneously  targeted  a  number  of 
fixed  platforms.  Clearly,  this  would  pose  a 
significant  problem  for  the  AWC  in  organization  F 
not  only  because  of  the  load  but  also  due  to  the 
need  to  focus  on  several  disjoint  areas  of  the 
battlespace  at  the  same  time.  Players  in  the  D 
organization  would  not  experience  as  much 
difficulty  in  countering  this  wave  since  the  load 
would  be  distributed  among  several  DMs,  with 
each  focussing  on  but  a  small  piece  of  the  AOR. 

A  number  of  waves  comprising  either  air,  surface, 
mines  or  search  and  rescue  tasks  were  constructed. 
A  wave  generally  consisted  of  between  3  and  5 
individual  tasks,  and  was  spaced  roughly  every 
300s  in  the  simulation  so  as  to  minimize  overlap 
with  successive  waves.  Overall  there  was  about 
two  air,  two  surface,  one  mine,  and  two  SAR 
waves.  In  some  cases  the  waves  were  adjusted  to 
coincide  with  time  critical  (pop-up  or 
unanticipated)  tasks  that  had  resource  requirements 
in  common  with  those  of  the  primary  wave. 

In  addition  to  the  adjustment  of  tasks  to  overload 
the  AWC,  ASuWC,  and  SOF/SAR  commander  in 
F,  we  also  adjusted  the  arrival  times  and  locations 
of  the  SCUD  missile  launchers  (SMLs)  in  scenario 
d  to  make  their  processing  in  F  more  difficult. 
Their  appearances  were  such  that  SMLs  arrived  in 
pairs,  in  separated  areas  within  countries  A  and  B. 
It  was  expected  that  this  would  be  more 
problematical  for  the  ISR  and  BMD  commanders 
in  F  than  for  two  players  in  D  where  each  one  was 
concerned  with  only  a  single  geographical  area. 

Spatial-Temporal  Loading:  Scenario  f 
In  scenario  f  the  task  “waves”  were  built  to  be 
relatively  easy  for  players  in  F,  while  being 
difficult  for  players  in  D.  Thus,  a  wave  typically 
consisted  of  a  number  of  tasks  with  different 
resource  requirements  focussing  on  a  narrow 
geographical  area.  An  example  of  such  a  wave 


might  be  a  coordinated  attack  on  DDGA  by  enemy 
air  and  enemy  surface  and/or  mines,  while  at  the 
same  time  requiring  the  DDGA  commander  to 
conduct  a  search  and  rescue  or  a  SCUD  task!  This 
would  create  an  overload  condition  for  the  targeted 
DM  in  the  D  organization.  But  since  these  tasks 
are  spread  over  several  functional  areas,  players  in 
the  F  organization  would  share  the  processing  load, 
and  so  this  “wave”  would  be  relatively  easier  to 
process  by  the  F  organization. 

There  were  approximately  8-10  such  multi¬ 
functional  waves  created  within  scenario  f,  each 
wave  lasting  for  about  200sec.  We  attempted  to 
have  each  player  node  in  D  experience  two  such 
waves  over  the  course  of  the  game.  As  was  the 
case  in  building  scenario  d,  the  waves  often 
coincided  with  time  critical  (pop-up  or  UT)  tasks 
especially  if  those  tasks  added  an  additional 
required  resource  category  to  the  “mix”. 

One  advantage  of  the  F  organization  is  that  one 
DM  owns  all  the  assets  to  process  a  large  class  of 
tasks.  No  negotiation  is  needed  among  DMs  as  to 
who  will  perform  which  task  and  with  which  asset, 
as  would  be  the  case  in  a  D  organization  with 
overlapping  areas  of  responsibility.  To  force  the 
need  for  players  in  D  to  coordinate,  the  flight  paths 
of  enemy  SCUD-launched  missiles  were  crafted  to 
“boundary  split”  the  areas  between  adjacent  DMs, 
as  were  the  paths  of  several  surface  threats,  and  the 
locations  of  enemy  missile  sites.  In  such  cases 
inter-DM  coordination  is  needed  within  D  to  most 
efficiently  apportion  the  team’s  scarce  assets 
(“who  will  do  the  task”),  but  such  coordination  is 
not  needed  in  F. 

6.4  Equivalence  between  Scenarios  f  and  d 
The  testing  of  congruence  involves  comparing  the 
performance  on  scenario  d  between  organization  D 
(congruent)  and  F  (incongruent).  The  reverse 
comparison  holds  for  scenario  f.  It  has  been 
suggested  that  the  experiment  could  also  provide  a 
comparison  between  performance  on  scenarios  f 
and  d  when  performed  by  a  single  organization  (D 
or  F).  This  type  of  cross-scenario  comparison 
depends  on  having  some  “equivalence”  between 
the  two  scenarios  in  terms  of  difficulty,  workload, 
etc.  Clearly,  if  scenario  f  was  significantly 
“easier”  than  scenario  d,  then  comparison  of 
performance  between  the  two  could  not  readily  be 
ascribed  to  an  organizational  dimension. 


The  two  scenarios  do  have  a  common  task  graph, 
primarily  to  ease  the  training  requirements  that 
were  deemed  to  be  excessive  if  players  had  to  learn 
two  entirely  different  task  graphs.  Since  the  two 
scenarios  are  markedly  different  in  their  task 
resource  requirements,  it  was  not  clear  how  to 
operationalize  “equivalence”.  One  could  talk 
about  numbers  of  tasks,  but  this  is  not  a  realistic 
mode  of  comparison  as  tasks  are  quite  different  - 
except  possibly  for  the  self-defend  tasks.  Instead, 
we  attempted  to  equalize  the  scenarios  by  adjusting 
the  number  of  tasks  in  each  scenario  such  that  the 
total  resource  demands  summed  over  all  tasks 
would  be  roughly  the  same.  This  is  computed  by 
summing  each  resource  category  ri  over  all 
scenario  tasks  that  have  ri  in  their  resource 
requirement  vector.  These  comparisons  are  shown 
in  Table  6. 


scenario 

AAW 

Mines 

ASuW 

BMD 

Strike 

SAR 

SOF 

f 

39 

10 

34 

20 

75 

16 

13 

d 

49 

9 

34 

20 

69 

16 

13 

Table  6:  f  and  d  scenario  comparisons 

The  numbers  are  equivalent  for  Mines,  ASuW, 
BMD,  SAR  and  SOF  categories.  Scenario  f  has 
greater  Strike  requirements,  while  d  has  higher 
AAW  requirements.  It  must  be  noted  however  that 
the  cross-functional  requirements  within  the  tasks 
themselves  are  absent  from  such  a  comparison  - 
the  coordination  demands  that  this  places  on  an 
organization  is,  of  course,  a  function  of  both  the 
scenario  and  the  organizational  structure. 

7.  Conclusions 

This  paper  presented  the  details  behind  the  design 
of  two  scenarios  that  were  used  in  a  team-in-the- 
loop  experiment  to  test  organizational  congruence. 
A  unique  aspect  of  this  work  was  the  “reverse” 
engineering  process  used  to  design  scenarios  d  and 
f,  starting  with  the  definitions  of  two  very  different 
organizational  structures  D  and  F.  A  second  aspect 
of  the  work  involved  the  use  of  the  analytical 
models  that  predict  the  degree  of  fit  (or 
congruence)  between  an  organization  and  the 
mission  it  faces.  These  model  predictions  guided  - 
at  virtually  every  step  -  the  selection  of  task 
requirements,  locations,  task  graph  dependencies, 
etc.,  that  in  total  define  a  scenario.  Iteration 
between  the  modelers  and  the  experimenters  in  our 
design  team  helped  assure  that  the  scenarios  to  be 
tested  in  the  laboratory  would  be  both 


reasonable/believable  and  model-driven  to  enable 
subsequent  model-data  comparisons. 

A  major  congruence  metric  (of  among  several)  is 
the  degree  of  inter-node  coordination.  As  this 
coordination  is  a  function  of  the  organizational 
structure  and  the  mission/task  requirements  the 
scenario  design  process  focused  considerable  effort 
on  the  selection  of  task  resource  requirements. 
Tasks  in  the  congruent  situations  (Ff  and  Dd)  were 
designed  to  require  low  inter-node  coordination, 
whereas  in  the  incongruent  cases  (Fd  and  Df)  tasks 
were  designed  to  have  higher  coordination 
demands.  The  tasks  used  for  this  instantiation 
included  the  major  mission  tasks,  time-critical  high 
priority  tasks,  and  several  others.  Another  metric 
that  enters  into  congruence  is  workload  imbalance. 
By  adjusting  the  spatial  and  temporal  arrivals  of 
the  tasks  that  dealt  with  defending  against  the 
enemy,  we  were  able  to  differentially  load 
individual  nodes  within  either  the  D  or  F 
organizations,  and  unevenly  load  the  team  in  the 
incongruent  cases  yet  for  the  same  scenario  have  a 
balanced/distributed  workload  in  the  congruent 
cases.  Other,  less  salient  manipulations  in  the 
scenarios  were  also  effected  (e.g.,  boundary 
splitting,  information  flows,  situational  awareness) 
that  were  geared  to  make  the  incongruent  cases 
relatively  more  difficult  than  the  congruent  case. 
In  short,  we  used  the  knowledge  gained  from 
earlier  laboratory-based  experiences  along  with 
guidance  from  model  predictions  to  design  the 
scenarios  and  “tune”  the  organizations. 

Experiment  8  was  conducted  in  August  and 
November  2002  at  the  Naval  Postgraduate  School 
using  eight  teams.  Four  teams  were  organized  as 
D  and  four  as  F,  and  each  team  was  exposed  to  the 
f  and  d  scenario  twice,  in  counterbalanced  order. 
A  companion  paper  [Diedrich  et  al,  2003] 
describes  results  that  convincingly  show  that 
performance  in  the  congruent  cases  significantly 
exceeded  that  in  the  non-congruent  cases.  Some  of 
the  measures  used  to  assess  performance  include 
number  of  tasks  accomplished,  accuracy, 
timeliness/latency.  Having  firmly  established  the 
value  of  congruence  as  a  construct  in  “optimal” 
organizational  design,  our  next  step  in  our  A2C2 
research  will  be  to  examine  the  processes  that 
teams  employed  to  try  to  overcome  poor 
performance  in  the  incongruent  cases,  whether 


players  were  aware  of  any  factors  that  caused  their 
performance  decrement,  and  what  human  teams 
are  likely  to  do  about  it:  e.g.,  adapt  their  structure 
(roles/responsibilities/assets)  or  just  cope? 
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